Web dispatch service

ABSTRACT

A system and method for accessing an application server includes sending a service command from a requester to a dispatch server, processing the service command on the dispatch server, translating the service command on the dispatch server into an application request to the application server, wherein the translating is based on a service definition stored on the dispatch server, and processing the application request. In one embodiment, the dispatch server includes a dispatch processor that is further programmed to manage a user interface, wherein the user interface includes a service registration interface, a service modification interface, and a service deletion interface.

FIELD OF THE INVENTION

[0001] The present invention is related to software applicationmanagement, and more particularly to the translation of simple servicerequests into complex web links.

BACKGROUND OF THE INVENTION

[0002] Computer science has forever grappled with solving the following,contrary statements: systems become more brittle as intelligence isdistributed, but systems also become less scalable as intelligence iscentralized. How can we enjoy the benefits of distributed scalabilitywith the superior availability and reliability of centralization? Therehas been a steady evolution of tools and methods to answer thisquestion. The advent of libraries and routines that could be included(linked) in multiple applications migrated to shared libraries thatmitigated the need to rebuild every application when a referencedroutine was changed. Later, the concept of objects promoted reuse andportability by only exposing necessary methods and properties to theusing application. Today, we routinely use object brokers that provideobjects as services to applications, further insulating developers fromthe intricacies of a desired capability while still providing thefunctionality required.

[0003] Another current example is the use of stored procedures to accessdatabase information rather than using specific structured querylanguage (SQL) commands in a given application. This moves a largeportion of database intelligence out of the application and into thedatabase server, which effectively centralizes more of the intelligencewhile distributing the capability. A change can be made to thecentralized stored procedure to fix a bug or add functionality to allapplications that use the procedure without requiring a change to eachapplication itself.

[0004] Today, however, we have no similar mechanism for minimizingintelligence required by one web application that needs to access theservices of another web application. For example, to display employeeinformation in a web application, one could use an employee lookupprogram. However, to use that application, one must know things such asthe server the application is currently running on, the path to and nameof the application, and what information the program needs to providethe desired service. All of this information may be encoded in aUniversal Resource Locator (URL) or link. This is not necessarily a lotof information to maintain, but if any of that information changes, thelink will break. As the number of copies of this link grow, and if thelink itself becomes more complex, then the maintenance could become moresignificant.

[0005] Clearly, the information required by a web application can beeven more involved in certain circumstances. For example, enablingapplications with Top Tier's Drag and Relate (DnR) capability, whilepowerful, can require significantly more intelligence in the enabledapplication. Additionally, most DnR Enabled Applications (DEAs) need toknow when they are DnR enabled, since displaying DnR links outside ofDnR aware environments could be confusing to the user, and simply won'twork if activated. Further, DEAs must encode information into the DnRlinks so the DnR servers understand what to do with the DnR link. Again,if any of that information changes, then the application will break.This approach becomes untenable in a large enterprise with manyapplications cross-linking each other.

[0006] For the reasons stated above, and for other reasons stated belowwhich will become apparent to those skilled in the art upon reading andunderstanding the present specification, there is a need for the presentinvention.

SUMMARY OF THE INVENTION

[0007] One aspect of the present invention provides a dispatch serverthat includes a data store having one or more entries that containapplication service information, and a dispatch processor operativelycoupled to the data store, wherein the dispatch processor is programmedto translate an application service to an application address. In someembodiments, the dispatch processor is further programmed to manage auser interface, wherein the user interface includes a serviceregistration interface, a service modification interface, and a servicedeletion interface.

[0008] Another aspect of the present invention provides a method foraddressing an application server. The method includes sending a servicecommand from a requester to a dispatch server, processing the servicecommand on the dispatch server, translating the service command on thedispatch server into a application address, redirecting the applicationaddress to the requester, and accessing the application server. In someembodiments, the application address is a complex address. In someembodiments, the processing of the service command includes validatingthe service command. In some embodiments, the processing of the servicecommand includes checking the service command for parameters.

[0009] Another aspect of the present invention provides a system thatincludes a dispatch server and a service user. The dispatch serverincludes a data store, and a processor programmed to translate a servicerequest into an application command. The service user is operativelycoupled to the dispatch server, wherein the service user sends theservice request to the dispatch server, and wherein the dispatch servertranslates the service request and sends the application command to theservice user.

[0010] Another aspect of the present invention provides a system thatincludes a dispatcher and an service provider. The dispatcher includes adata store, and a processor programmed to translate a service requestinto an application address and manage a user interface, wherein theuser interface includes a service registration. The service provider isoperatively coupled to the dispatcher, wherein the service providerregisters its services with the dispatcher through the user interface.

[0011] Another aspect of the present invention provides a method forcentralized management of complex web links on a web dispatch provider.The method includes storing application service definitions and complexweb link data in a centralized database of the web dispatch provider,receiving service requests from a browser, sending redirectedapplication requests to a browser, and changing the complex web linkdata in the centralized database without changing the applicationservice definitions.

[0012] Another aspect of the present invention provides a method forregistering services on a web dispatch server. The method includessending a registration request from an application server to the webdispatch server, the registration request having a first service name,processing the registration request on the web dispatch server,registering a new service for the registration request on the webdispatch server, the new service having a second service name, andstoring the new service in a web dispatch database, such that a user canaccess the new service of the application server by sending a servicerequest to the web dispatch server.

BRIEF SUMMARY OF THE DRAWINGS

[0013] In the following drawings, where the same number reflects similarfunction in each of the drawings,

[0014]FIG. 1A is a high-level component view of a dispatch serveraccording to one embodiment of the present invention;

[0015]FIG. 1B is a high-level component view of a dispatch server and anadditional server according to another embodiment of the presentinvention;

[0016]FIG. 2 is a detailed view of a set of entries in a data store ofthe dispatch server according to one embodiment of the presentinvention;

[0017]FIG. 3A is a block diagram illustrating a system that includes adispatch server, an application server, and a client, according to oneembodiment of the present invention;

[0018]FIG. 3B is a block diagram illustrating a system that includes adispatch server, an application server, and a client, according toanother embodiment of the present invention;

[0019]FIG. 3C is a use-case diagram illustrating various use cases indifferent embodiments of the present invention;

[0020]FIG. 4 is a flow chart illustrating a method for translatingservice requests into application requests according to one embodimentof the present invention;

[0021]FIG. 5A is a flow chart illustrating a method for managingservices through a user interface of a dispatch server according to oneembodiment of the present invention;

[0022]FIG. 5B is a continuation of the flow chart shown in FIG. 5Aillustrating a method for managing services through a user interface ofa dispatch server according to one embodiment of the present invention;

[0023]FIG. 6 is a textual view of an example of a service request sentto a dispatch server according to one embodiment of the presentinvention;

[0024]FIG. 7 is a textual view of an example of a translation of aservice command into an application command according to one embodimentof the present invention;

[0025]FIG. 8 is a textual view of an example of service invocationcompression according to one embodiment of the present invention;

[0026]FIG. 9 is a textual view of an example of service requesttranslation and parameter formatting according to one embodiment of thepresent invention;

[0027]FIG. 10 is a textual view of an example of service requesttranslation and parameter defaults according to one embodiment of thepresent invention;

[0028]FIG. 11 is a textual view of an example of service request andmethod translation using form data according to one embodiment of thepresent invention; and

[0029]FIG. 12 is a textual view of an example of service request andmethod translation parameter transparency according to anotherembodiment of the present invention.

DETAILED DESCRIPTION

[0030] In the following detailed description of the preferredembodiments, reference is made to the accompanying drawings which form apart hereof, and in which is shown by way of illustration specificpreferred embodiments in which the inventions may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the invention, and it is to be understood thatother embodiments may be utilized and that logical, mechanical andelectrical changes may be made without departing from the spirit andscope of the present invention. In certain embodiments, reference ismade to certain outside technologies to exemplify the utility of theseembodiments of the invention. These technologies are not associatedwith, or required by, these embodiments of the invention for operation,but are described only to demonstrate the flexibility and utility ofthese embodiments of the invention in various operating environments.The following detailed description is not to be taken in a limitingsense, and the scope of the present invention is defined by the claims.

[0031] Introduction

[0032] It is interesting to consider web pages and applications in termsof objects and transactions. One can consider a single, static web pageas a simple object with a single method called “display my contents.”The method is invoked via the web link for that page. Web pagesgenerated by an application are just slightly more complex objects thatnow include zero or more properties. These properties are sent to theapplication in the link itself or through other data that a browser cansend to the link's destination. Thus, the method of an application isjust a bit more complex and may be called something like “display mycontents based on my properties.”

[0033] By the nature of the environment, web applications aretransaction-based. A web application is nothing more than a collectionof web pages presented to a browser with a common look, feel, andpurpose. The web environment itself neither cares nor knows about anyapplication, and is, in fact, stateless. The web is only concerned withrequests and responses. Using an employee lookup program (i.e. whitepages) example, an entry page might present a list of many things thatcan be done, such as looking up an employee by last name (or byuser-name or employee number), or searching the phone book for phonenumbers, parts of names, etc. In fact, each of these capabilities is atransaction that may be executed independent of the others as long asthe correct information is passed to the right server.

[0034] This object and transaction orientation makes the web veryflexible and powerful. This same capability, however, can also causereliability, availability, and scalability (RAS) issues in an enterpriseif not carefully managed. RAS issues have been around in the softwaredevelopment field for many years, and new technologies have evolved overtime to address them. Such technologies are less mature in the webenvironment. Certain embodiments of the present invention describedbelow apply some of the lessons learned in traditional softwaredevelopment to a web environment of linked objects and transactions.

[0035] Description of the Preferred Embodiments

[0036]FIG. 1A is a high-level component view of a dispatch serveraccording to one embodiment of the present invention. In thisembodiment, dispatch server 100 is located on the World Wide Web, andincludes data store 110 and dispatch processor 120. Dispatch processor120 includes translator 130 and service management (user) interface 140,and is operatively coupled to data store 110. Data store 110 has one ormore entries that contain application service information, and dispatchprocessor 120 is programmed to translate an application service requestvia translator 130 into an application address. In this embodiment,service management interface 140 includes service registration 150,service modification 160, and service deletion 170. Dispatch processor120 is further programmed to manage service management interface 140.Dispatch server 100 shown in FIG. 1A has various functionalities. Indifferent embodiments, dispatch server 100 includes functionalities forservice-to-application translation, service registration, serviceavailability, parameter formatting, parameter completion (or defaults),method translation, and source routing. Service-to-applicationtranslation enables a link to reference a service, rather than aparticular application with all its required parameters, etc. Serviceregistration allows new applications to register their services andusages. Service availability allows users to discover which services areavailable from different application providers. Service modificationallows applications to modify or delete their services afterregistration. Parameter formatting allows a link to contain parameterswithout knowledge of the required format of those parameters, and alsoallows support for different formatting of the same parameter fordifferent applications. Parameter completion allows links to includeonly a subset of all required parameters to a target application. Methodtranslation allows links to include parameters for target applicationswithout knowledge of the method required.

[0037]FIG. 1B is a high-level component view of a dispatch server and anadditional server according to another embodiment of the presentinvention. In this embodiment, service management interface 140 isincluded in a separate and distinct run-time server 101 than dispatchserver 100. Server 101 is operatively coupled to dispatch server 100.Server 101 includes processor 121. Processor 121 is programmed to manageservice management interface 140. This dual-server architecture improvesstability of the overall run-time system. One server, such as server101, may go down while the dispatch server 100 is still functional. Inthis scenario, applications could not register, modify, or deleteservices on server 101, but clients could still invoke services ondispatch server 100. Considering the potential high transaction-rate ofdispatch server 100, one embodiment includes a system with dispatchserver 100 as a large-scale server, and server 101 as a cheaper, smallerplatform.

[0038] In the embodiments shown in FIGS. 1A and 1B, dispatch server 100is very flexible, such that it can operate in many different types ofenvironments. Certain environments require specific application servicemessage protocols and language definitions. Dispatch server 100functions within these environments, wherein the application serversimplementing any specific protocols or service language definitions willinterface cleanly with dispatch server 100 during run-time operation.

[0039]FIG. 2 is a detailed view of a set of entries in a data store ofthe dispatch server according to one embodiment of the presentinvention. In this embodiment, data store 110 includes entries 180through 190 that contain application service information about service₁through service_(A). Entry 180 includes information about a firstapplication service 181 (service₁). The information of entry 180corresponding to service₁ 181 is contained within data entry 182 (data₁)through data entry 183 (data_(B)). Data entries 182 through 183 includevarious data information about service₁ 181. Data entries 182 through183 includes information that is specific to service₁ 181, and arereferenced by dispatch processor 120 of dispatch server 100. In someembodiments, data entries 182 through 183 include definitions forenablement and disablement of service₁ 181. Service₁ 181 is a servicethat has been registered on dispatch server 100 by an applicationprovider. Data entries 182 through 183 can dynamically change over time,such that the definition of service₁ 181 is configurable. Entry 190includes information about an A^(th) application service 191(service_(A)). The information of entry 190 corresponding to service_(A)191 is contained within data entry 192 (data₁) through data entry 193(data_(C)). Data entries 192 through 193 include various datainformation about service_(A) 191. Data entries 192 through 193 includesinformation that is specific to service_(A) 191, and are referenced bydispatch processor 120 of dispatch server 100. In some embodiments, dataentries 192 through 193 include definitions for enablement anddisablement of service_(A) 191. Service_(A) 191 is a service that hasbeen registered on dispatch server 100 by an application provider. Dataentries 192 through 193 can dynamically change over time, such that thedefinition of service_(A) 191 is configurable.

[0040]FIG. 3A is a block diagram illustrating a system that includes adispatch server, an application server, and a client, according to oneembodiment of the present invention. In this embodiment, system 200includes dispatch server 100, application server 210, and client 220. Insome embodiments, client 220 may also be an application server. Dispatchserver 100 is operatively coupled to both application server 210 andclient 220. Client 220 is operatively coupled to both dispatch server100 and application server 210. Application server 210 is operativelycoupled to both dispatch server 100 and client 220. System 200 providesclient 220 with the ability to address application server 210. Client220 sends service request 230 to dispatch server 100. Dispatch server100 processes service request 230 and translates service request 230into an application request 240. Dispatch server 100 redirectsapplication request 240 back to client 220. Client 220 receivesapplication request 240 and forwards it as application request 280 toapplication server 210. Application server 210 processes applicationrequest 280, and sends application response 270 to client 220. In system200, client 220 is an end-user.

[0041] This embodiment provides several advantages. First, system 200 ismore reliable, because the transaction time between client 220 anddispatch server 100 is quite small. Dispatch server does not need tomaintain state information about its transaction with client 220, andtherefore the transaction rate can be quite high. Second, system 200provides a clearer security model, because client 220 directly invokesapplication request 280 to application server 210 (i.e. dispatch server100 redirects application request 240 back to client 220, rather thansending it to application server 210). This provides a clearer securitymodel and eases cookie management.

[0042] To further exemplify the advantages of this embodiment, we canuse two analogies. The first analogy is that of a taxi service. Asidefrom not having to drive, a key benefit is that we don't need to knowwhere a destination is, or how to get there. We can just hop in and askto be taken to a certain location, and a while later, we arrive there.For less common destinations, we may have to provide a specific addressto the taxi driver, but we still don't have to know how to get there.And, for generic locations, we may not even need to know the name of thelocation. For example, we might just say to the taxi driver, “Take me tothe closest book store.” This is an example of how we minimize theinformation we need to do something (i.e. get to a destination) byrelying on another source (i.e. the taxi driver) for that information.

[0043] The second analogy is that of a vacation in Mexico. Let's say youdecide to vacation in Mexico and don't speak Spanish, but your travelingcompanion does. While in a restaurant, you need to use a restroom (whichyou are quite certain that the restaurant has). You ask your travelingcompanion for help. She tells you how to ask for the restroom inSpanish, and further informs you that you can ask a clerk in therestaurant, such that the clerk will understand your request, and alsobe able to give you a correct response (as to how to find the restroom).There are at least two important points in this analogy: (1) yourtraveling companion did not ask for you, but told you how to ask, and(2) your traveling companion also told you where to ask. By correctlyformatting (and redirecting) an application request in this embodiment,the dispatch server is basically telling you how and where to ask. Byreturning the application request in a redirect message, the dispatchserver is letting the client make the request, not actually calling thetarget application server directly.

[0044] In some embodiments, application requests 240 and 280 are complexaddresses. In other embodiments, service request 230 includes a URL. Inother embodiments, the processing of service request 230 on dispatchserver 100 includes validating service request 230, and checking servicerequest 230 for parameters.

[0045] In the embodiment shown in FIG. 3A, application server 210 alsosends user interface commands 250 to dispatch server 100. These userinterface commands 250 will be processed by the user interface ofdispatch server 100, and then user interface responses 260 will be sentback to application server 210. In this way, application server 210 canregister services on dispatch server 100. In another embodiment,application server 210 can modify and delete services on dispatch server100. In this way, service definitions can change without having tochange service requests. Dispatch server 100 has centralized managementof complex web links, such that client 220 sends the same servicerequest 230 to dispatch server 100 after the service definitions havechanged. In some embodiments, client 220 sends additional commands todispatch server 100 to discover which services are currently available.

[0046]FIG. 3B is a block diagram illustrating a system that includes adispatch server, an application server, and a client, according toanother embodiment of the present invention. In this embodiment, system201 includes dispatch server 100, application server 210, and client220. Dispatch server 100 directly sends application request 240 toapplication server 210. Application server 210 processes applicationrequest 240, and sends application response 270 back to dispatch server100. Dispatch server includes an amount of state information, so that itcan send application response 271 to client 220. In this case, dispatchserver 100 acts substantially similar to a reverse proxy. Client 220never needs to know the exact address of application server 210, nordoes it need send requests to application server 210. Dispatch 100handles all of the transactional work with application server 210.Client 220 only needs to send simple service requests to dispatch server100, and in one embodiment, these requests can easily be bookmarked asURL favorites on client 220.

[0047]FIG. 3C is a use-case diagram illustrating various use cases indifferent embodiments of the present invention. In this embodiment,use-case diagram 281 shows use cases involving a service user 283 and aservice provider 282. In one use case, service provider 282 implementsuse 292 for use case 284 to register a service on a dispatch provider.User interface 291 aids in the registration process. Database 290 isupdated to include the new service. In another use case, service user283 implements use 296 for use case 288 to invoke a service on thedispatch provider. Dispatcher 289 handles the service request sent fromservice user 283, and database 290 is used to query information aboutthe requested service.

[0048] In another embodiment, service user 283 implements use 295 foruse case 287 to discover available services on the dispatch provider.User interface 291 aids in the discovery process, and database 290 isused to query information about available services on the dispatchprovider.

[0049] In another embodiment, service provider 282 implements use 293for use case 285 to modify an existing service on the dispatch provider.User interface 291 aids in the modification process, and database 290 isupdated for the modified service.

[0050] In another embodiment, service provider 282 implements use 294for use case 286 to delete an existing service on the dispatch provider.User interface 291 aids in the deletion process, and database 290 isupdated to delete the indicated service.

[0051]FIG. 4 is a flow chart illustrating a method for translatingservice requests into application requests according to one embodimentof the present invention. In this embodiment, flow diagram 300 beginswith step 310, when dispatch server 100 receives a service request froma browser. In step 320, dispatch server 100 parses the request todetermine the format and contents of the request. At checkpoint 330,dispatch server 100 determines if the service request is valid. If it isnot, an error message is displayed, and an error is returned to thebrowser. If the service request is valid, dispatch server then checks ifthe service invoked by the service request is in data store 110 atcheckpoint 340. Data store 110 contains service data entries(definitions) for each of the services registered on dispatch server100. If the service is not located in data store 110, an error messageis displayed, and an error is returned to the browser. If the service isin data store 110, then dispatch server next determines if the serviceis available at checkpoint 350. If the service is not available, anerror message is displayed, and an error is returned to the browser. Ifthe service is available, step 360 then resolves the service requestinto an application request. To do this, dispatch server 100 referencesdata store 110 to determine the service definitions that are relevant tothe invoked service. At checkpoint 370, dispatch server 100 determinesif the service request contains any parameters. If the request does notcontain any parameters, then dispatch server redirects the applicationrequest to the browser in step 430. If the request does containparameters, then dispatch server determines if the parameters are validfor the indicated service at checkpoint 380. Again, dispatch serverreferences data store 110 in determining if these parameters are validfor the particular service in question. If the parameters are invalid,an error message is displayed, and an error is returned to the browser.If the parameters are valid, dispatch server 100 processes theparameters in step 390. At checkpoint 400, dispatch server determines ifany of the parameters are POST method parameters. As will be describedin more detail below, parameters may be passed to an application servervia the POST method, which passes parameters in data (other than in theURL) that is sent to the application server. If there are no POST methodparameters, then dispatch server 100 redirects the application requestto the browser in step 430. If there are POST method parameters, thendispatch server 100 creates a form using these parameters in step 410.In step 420, dispatch server 100 returns the form with an invocation ofthe onload event that calls the form's submit method, and then redirectsthe application request (which includes the form) to the browser in step430. Flow diagram 300 ends with step 450.

[0052]FIGS. 5A and 5B (hereinafter referred to collectively as FIG. 5)show a flow chart illustrating a method for managing services through auser interface of a dispatch server according to one embodiment of thepresent invention. In this embodiment, user interface requests can beused to add, delete, and modify services and service definitions on thedispatch server. Flow diagram 500 begins with step 510, when a userinterface request is received by the dispatch server. As discussedearlier, this user interface request will be sent to the dispatch serverfrom an application server. In step 520, a welcome page with links willbe displayed on dispatch server 100. At checkpoint 530, dispatch server100 determines if the user interface request has made a selection toview registered services on dispatch server 100. After such a selectionis made, dispatch server 100 displays all available services fromdatabase 110. Database 110 includes information for all currentlyregistered services on dispatch server 100.

[0053] At checkpoint 660 of FIG. 5, dispatch server 100 determines ifthe user interface request includes a request to add a new service. Ifthe request is to add a new service, step 670 enters the name of the newservice from the request. In one embodiment, the request is parsed toextract the new service name. Step 680 checks database 110 for a similarservice name. Database 110 includes information for all currentlyregistered services on dispatch server 100. At checkpoint 690, dispatchserver 100 determines if the new service name is unique from otherservice names currently registered in the system. If the name is notunique, control is returned to step 670 to enter another name for thenew service. If the name is unique, then step 700 enters the servicedefinition from the user interface request. In one embodiment, the userinterface request is parsed to extract the service definition. After theservice definition has been entered, the new service is registered instep 710 into database 110. Database 110 at this point contains theservice definition for the new service. At checkpoint 720, dispatchserver 100 determines if the service has parameters. If it does not,then dispatch server 100 determines if any more services are to be addedat checkpoint 730. If the service does have parameters, then theparameters are entered in step 740. In one embodiment, the userinterface request is parsed to extract the parameters. In step 750, thenew parameters are registered into database 110 for the new service.

[0054] At checkpoint 550 of FIG. 5, dispatch server determines if theuser interface request includes a request to edit an existing service.If the user interface request includes such a request, then step 560queries database 110 to display the current service definition for thegiven service. In one embodiment, the user interface request is parsedto extract service information. At checkpoint 570, dispatch server 100determines if the user interface request includes a request to delete aservice. If it does not, the service definition is edited at step 590.Then, at checkpoint 600, dispatch server 100 determines if theparameters are to be edited. If they are not, then the service isupdated in step 610 and database 110 is also updated for the editedservice. If the parameters are to be edited at checkpoint 600, thencurrent parameters are displayed in step 620. At the next checkpoint630, dispatch server 100 determines if a parameter is to be deleted. Ifnot, then the parameter definitions are edited in step 650, and theservice is updated in step 610 (such that database 110 is updated). Ifthe parameter is to be deleted, then the parameter is removed fromdatabase 110 in step 640. If dispatch server 100 determines that theservice is to be deleted at checkpoint 570, then the enter service isremoved from database 110 in step 580.

[0055]FIG. 6 is a textual view of an example of a service request sentto a dispatch server according to one embodiment of the presentinvention. In this embodiment, the core feature provided by the dispatchserver is the ability to abstract the details of a specific web addressinto a generic service definition that hides much of the intelligencetypically required in a link. Service request 800 shows the basic formatfor linking to a web application that is defined as a dispatch service.Textual element 801 of service request 800 is the name of the dispatchserver. Textual element 802 of service request 800 is the name of aregistered service on the dispatch server. Textual element 803 ofservice request 800 contains the parameters and/or values required forthe indicated service. Thus, in this embodiment, a service request 800sent to a dispatch server includes a dispatch server name, a registeredservice name, and parameter values. In some embodiments, the servicerequest includes only a dispatch server name and a registered servicename.

[0056]FIG. 7 is a textual view of an example of a translation of aservice command into an application command according to one embodimentof the present invention. In this embodiment, an example of an employeelookup program is used to demonstrate the service-to-applicationtranslation capabilities of the dispatch server. Service command 810 istranslated into application command 820 by a dispatch server. Textualelement 811 of service command 810 is the communication protocol.Textual element 812 of service command 810 is the name of the dispatchserver. Textual element 813 of service command 810 is the name of aregistered employee lookup service on the dispatch server. At someprevious time, the client who has sent this service command hasdiscovered this service by name on the dispatch server. Textual element814 of service command 810 is the parameter required by the serviceindicated by textual element 813. This parameter can be sent directly inservice command 810. The dispatch server of this embodiment of theinvention translates the service command 810 into application command820. Application command 820 includes textual elements 821, 822, 823,and 824. Textual element 821 is the communication protocol. Textualelement 822 is the name of the server running the particularapplication. Application command 820 is sent to this server. Textualelement 823 is the path and name of the application running on theserver. Textual element 824 is the information that the applicationneeds in order to return the desired information for employee number 48.

[0057] In this embodiment, service registration and request redirectionfunctionalities allow the dispatch server to translate service command810 into application command 820. Before service command 810 arrives atthe dispatch server, the employee lookup application owner must registerthe “employee_lookup_by_workno” service with the dispatch server,including a required parameter “emp” that designates a single employeenumber. Additionally, during registration, dispatch server must storedata for the given service indicating that the program “emp/default.asp”on server “iisprod” must be invoked with a single parameter “emp.”Parameters may be passed to an application using a GET method, and alsomay be passed using a POST method. The GET method passes parameters toan application directly in the address (e.g. URL). The POST methodpasses parameters in other data that is sent to the application. In thepresent embodiment, the parameter “emp” is passed using the GET method.In some embodiments, the dispatch server also stores data for the givenservice that associates a description and owner with the service, andthis information is provided to clients during service discovery.

[0058] After service registration, a client sends service command 810 tothe dispatch server. After service command 810 is translated intoapplication command 820 by the dispatch server, application command 820is redirected back to the client. By sending the client back theapplication command in a redirect message, the dispatch server lets theclient make the request to the application server directly. Thisapproach has certain benefits. After the dispatch server has translatedthe request, it is basically done. This involves a simple database queryand some possible data formatting, all of which can be done quitequickly. The dispatch server then sends a small amount of data back tothe client. It does not have to wait for the target application torespond, nor does it route the results from the target application backto the client. This means that the dispatch server does not need tomaintain any state information, and that the dispatch server will beable to handle many service commands per second. Further, theapplication command redirection approach minimizes the network path (andtraffic) for the results to get from the target application back to theclient. It also is important for usage logging, access tracking, andsecurity management.

[0059] In another embodiment, the dispatch server directly sendsapplication command 820 to the application server, and routes anapplication response back to the client. In this embodiment, thedispatch server would need to maintain some state information.

[0060] In yet another embodiment, the service registration process is atleast partially automated. In this embodiment, a dispatch interface isdesigned so that an application can register itself for all of itsavailable services. In one specific embodiment, the Extensible MarkupLanguage (XML) provides a simple, hierarchical messaging protocolwhereby the required service components are described, filed, andupdated by existing applications.

[0061] In yet another embodiment, the dispatch server provides currentlyavailable service information to clients who send service inquiryrequests to the dispatch server. In this way, clients find out about(i.e. discover) services offered by the dispatch server. In one specificembodiment, a client can inquire about a reserved service, such as aservice named “info,” from the dispatch server. After receiving thisinquiry, the dispatch server would return information about itself tothe client. Further, if the “info” service is called with a “services”parameter (which is a reserved parameter name for the reserved service“info”), then the dispatch server will directly respond to the clientwith a list of published services, their names, required parameters, adescription, and human contact information. In another embodiment, theservice inquiry (i.e. discovery) process is also at least partiallyautomated. In this embodiment, an XML-enabled interface is provided,such that clients inquire which services are available, and how toaccess them.

[0062]FIG. 8 is a textual view of an example of service invocationcompression according to one embodiment of the present invention. Inthis example embodiment, service invocation 830 is compressed into asmaller service invocation 840. Both service invocations 830 and 840 ofthe present embodiment are in Uniform Resource Locator (URL) format. Itis widely known that some web browsers and servers limit the length of aURL to 255 characters, which in turn limits the amount of informationthat can be passed to an application via the path or GET method. Becausethe web dispatch service limits the amount of information required inthe links, the service also has the effect of compressing a URL (such asin a service invocation), which is to say that more information can beimplicitly communicated in less space. Service invocation 830 includestwo GET method parameters, “var1” and “var2”. The “var1” parameter isset equal to “value1” and the “var2” parameter is set equal to “value2.”Service invocation 840 takes full advantage of URL compression viaparameter translation. The values “value1” and “value2” are passeddirectly in the service invocation, thus making service invocation 840more compact.

[0063] Additional decoupling is available between calling and targetapplications if the dispatch server provides parameter formatting. Thisnot only removes the burden of parameter formatting from the callingapplication, but also eliminates the need to possibly support multipleformatting of the same parameter for different target applications. FIG.9 is a textual view of an example of service request translation andparameter formatting according to one embodiment of the presentinvention. In this embodiment, service request 850 is translated intocontent request 860, such that one of the parameters of the servicerequest is properly formatted. Service request 850 includes a DnRservice. Although FIG. 9 (and some of the other figures and portions ofthe present specification) make referene to DnR capabilities of TopTier's Drag and Relate, these figures are used only as examples to showthe utility of these embodiments of the present invention in variousoperating environments. Top Tier's Drag and Relate technologies are inno way associated with, or required by, these embodiments of the presentinvention. They are shown in the figures and further described only toexemplify the flexibility of use of a dispatch server in certainoperating environments of these embodiments.

[0064] To send content request 860 to a DnR server, the DnR serverrequires the employee number to be an 8 digit integer with zero leftpadding. (In this scenario, DnR server is a content server.) In thisinstance, the formatting is performed by the dispatch server, and theformatting code is eliminated from the employee lookup program (i.e.client). FIG. 9 shows the format of the call to the dispatch server andthe URL that is re-directed back to the client. We assume that theservice “dnr_return_workno” has been previously registered with thedispatch server and in doing so, the format of the parameter isspecified as an 8 digit integer with zero left padding. Content request860 is a DnR link, where “hrnp://” is the Hyper Relational NavigationProtocol (for Top Tier Drag and Relate). “ntitsqaw03:9997” is the server(on port 9997 in this case). “BUS1065” is the name of the object.“OBJECTKEY” is the name of the objectid. And “00000048” is the parameterformatted that is being drag and related for employee number 48.

[0065] It should be noted that the example shown in FIG. 9 is somewhatartificial, in that DnR links in DEAs (DnR Enabled Applications) areonly meant, as the name implies, to be drug to a DnR aware server andnot simply clicked on as are other HTML links. Therefore, the clientcannot return content request 860 as specified above. The link shownmust be available as is so it is dragable (i.e., since we don't actuallyclick on the link, it can't be sent to the dispatch server forinterpretation). In FIG. 10, we present another embodiment of thedispatch server and demonstrate a more legitimate way to engage thedispatch server to remove DnR intelligence from DEAs.

[0066] Another key feature of another embodiment of a dispatch server isaccepting a service request from a client that has only a subset of atarget application's required parameters. This is to say that thedispatch server can provide default parameters if they are omitted.Continuing with the example embodiment above in FIG. 9, our goal is toremove intelligence from the employee lookup program (i.e. client), yetstill allow it to be fully DnR enabled. The worker information isdynamic and must be passed to the employee lookup program in each call.However, the DnR information is static and constant across all calls.FIG. 10 is a textual view of an example of service request translationand parameter defaults according to one embodiment of the presentinvention. In this embodiment, service request 870 is translated intoapplication link 880. We define a variable DNR that if present (via theGET or POST method) indicates to a target application that it is in DnRmode. We can further require that the value of the DnR variable be theDnR enabled link that the application must display. In FIG. 10, theembodiment of the dispatch server's parameter completion feature furtherremoves intelligence from the calling application. In FIG. 10, we assumethat the service “employee_lookup_by_workerno_withDNR” has beenpreviously defined with two parameters, one being the required employeenumber (emp), and also a second optional parameter (DNR) with a defaultvalue of “hrnp://ntitsqaw03:9997/BUS1065/OBJECTKEY/#PARAM#emp”. Here,the “#PARAM#” string tells the dispatch server to substitute the valueof another, non-default parameter, which in this case is “emp” that hasa value of 48. When registering this application, we also expect thatthe default “DNR” parameter was specified to require left-zeroformatting.

[0067]FIG. 11 is a textual view of an example of service request andmethod translation using form data according to one embodiment of thepresent invention. In this embodiment, the dispatch server is able tohandle the case when a target application (on a service provider) isexpecting parameters via the POST method. Dispatch server translatesservice request 890 into application link 900, wherein application link900 includes the required POST method parameters with the form's“action” variable set to the target application's URL. In addition,application link 900 also includes an invocation of the “onload” eventthat calls the form's “submit” method. As soon as the form is receivedby the client from the dispatch server, it is immediately submitted,which is consistent with the redirect method used with the GET and pathparameters (directly passed in the URL path) described in earlierembodiments of the invention. The two parameter values “value1” and“value2” are passed to the dispatch server via the path method have beentranslated to POST method variables via the form, and that a thirdparameter “var3” has been added as well. This third parameter isrequired by the application and automatically supplied by dispatch usingparameter completion with its default value, “value3”. In thisembodiment, additional bookmarking of applications is also allowed withthe type of form data shown in application link 900. Typically,applications requiring POST method parameters cannot be bookmarked (orsaved as a URL favorite), because there is no way to store theparameters in the URL, which is all that is saved in a bookmark. Byallowing the parameters to be specified in a URL and later converted viathe dispatch server to the expected POST method, an application thatpreviously did not support bookmarking now does.

[0068]FIG. 12 is a textual view of an example of service request, methodtranslation, and parameter transparency according to another embodimentof the present invention. In this embodiment, if path or parameterinformation is passed to the dispatch server for which no associatedparameters are listed, then the dispatch server will simply pass on thepath or parameter information in the same manner in which it wasreceived. This provides maximum flexibility for migrating links to takefall advantage of the dispatch service. In FIG. 12, service request 910having GET parameters (“var1” is implicitly provided by “value1,” and“var2” is explicitly provided as “value2”) is translated into POSTmethod application request 920. In this embodiment, “var2” is notdefined in the service database of the dispatch server, and thus it issimply passed along transparently as a parameter from service request910 into application request 920, while “value1” is translated into aPOST method parameter, and “value3” is supplied as a default value.

[0069] In another embodiment of the present invention, the dispatchserver provides source routing. In this embodiment, service requests aretranslated into application requests just as before. However, during thetranslation process, the dispatch server determines the geographiclocation of the requesting client and one or more application serversthat provide the requested service. That is to say, there can be manyapplication servers in different geographic locations that provide therequested service. Source routing occurs when the dispatch serverdetermines the closest application server to the requesting client whentranslating a service request and redirecting an application requestback to the client. For example, in a specific embodiment, applicationservers in the United States, Italy, and Japan all provide a commonservice of “employee_stock_quoting.” A client in Italy sends a servicerequest for “employee_stock_quoting” to the dispatch server. Thedispatch server will achieve source routing by assessing the client'slocation (Italy), and determining that the nearest application serverthat provides the requested service is the one in Italy. The dispatchserver will redirect an application request back to the client, whereinthe application request includes the address of the application serverin Italy.

[0070] In another embodiment, the dispatch server uses a load-balancingstrategy when choosing the appropriate application server and therebycreating an application request. In this way, routing of requests isachieved to maximize the load-balancing strategy used by the dispatchserver. This occurs when multiple application servers in a givengeographic location provide the requested service. The dispatch serverimplements a load-balancing strategy to determine which applicationserver will handle the application request. In one embodiment, theload-balancing strategy includes a round-robin strategy.

CONCLUSION

[0071] Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiment shown. This application isintended to cover any adaptations or variations of the presentinvention. Therefore, it is intended that this invention be limited bythe claims and the equivalents thereof.

What is claimed is:
 1. A dispatch server comprising: a data store havingone or more application service definitions, wherein each applicationservice definition includes a service name and one or more service dataentries; and a dispatch processor operatively coupled to the data store,wherein the dispatch processor is programmed to translate a servicerequest into an application request, wherein the translation is at leastpartially based on one of the application service definitions.
 2. Thedispatch server of claim 1, wherein the dispatch processor is furtherprogrammed to subsequently translate the service request into adifferent application request, wherein the subsequent translation is atleast partially based on a changed application service definition. 3.The dispatch server of claim 1, wherein the dispatch processor isfurther programmed to manage a user interface, wherein the userinterface includes a service registration interface, a servicemodification interface, and a service deletion interface.
 4. Thedispatch server of claim 1, wherein the dispatch server is located onthe World Wide Web.
 5. A method for accessing an application owner, themethod comprising: sending a service command from a requestor to adispatch server; processing the service command on the dispatch server;translating the service command on the dispatch server into anapplication request to the application owner, wherein the translation isat least partially based on a service definition stored on the dispatchserver; and processing the application request.
 6. The method of claim5, wherein the processing of the application request comprises:redirecting the application request to the requestor; and sending theapplication request from the requester to the application owner.
 7. Themethod of claim 5, wherein the processing of the application requestcomprises: sending the application request from the dispatch server tothe application owner; sending an application response from theapplication owner to the dispatch server; and sending the applicationresponse from the dispatch server to the requester.
 8. The method ofclaim 5, wherein the processing of the service command includesvalidating the service command, and checking the service command forparameters.
 9. The method of claim 5, wherein the service commandincludes a Universal Resource Locator.
 10. A method for accessing acomplex web link, the method comprising: sending a service request froman end-user to a dispatch server; translating the service request into acomplex application command, wherein the translating is at leastpartially based on a service definition stored on the dispatch server;redirecting the complex application command from the dispatch server tothe end-user; sending the complex application command from the end-userto a service provider; and sending an application response from theservice provider to the end-user.
 11. A system comprising: a dispatchserver comprising: a data store; and a processor programmed to translatea service request into an application command, wherein the translationis at least partially based on a service definition stored in the datastore; and a service user operatively coupled to the dispatch server,wherein the service user sends the service request to the dispatchserver, and wherein the dispatch server translates the service requestand sends the application command to the service user.
 12. The system ofclaim 11, wherein the system is located on the World Wide Web.
 13. Thesystem of claim 11, wherein the system further includes an independentservice management server.
 14. The system of claim 13, wherein theindependent service management server includes a processor programmed tomanage a service registration interface, a service modificationinterface, and a service deletion interface.
 15. A system comprising: adispatcher comprising: a data store; and a processor programmed totranslate a service request into an application request and manage auser interface, wherein the translation is at least partially based on aservice definition stored in the data store, and wherein the userinterface includes a service registration; and a service provideroperatively coupled to the dispatcher, wherein the service providerregisters its services with the dispatcher through the user interface.16. The system of claim 15, wherein the user interface of the dispatcherfurther includes service modification and deletion.
 17. The system ofclaim 15, and further comprising a service user operatively coupled toboth the dispatcher and the service provider, wherein the service usersends a service request to the dispatcher, wherein the service userreceives an application request from the dispatcher, and wherein theservice user sends the application request to the service provider. 18.A method for centralized management of complex web links on a webdispatch provider, the method comprising: storing an application servicedefinition in a centralized database of the web dispatch provider,wherein the application service definition includes a service name andone or more service data entries; receiving a first service request froman end-user; translating the first service request into a firstapplication request, wherein the translating is at least partially basedon the application service definition; redirecting the first applicationrequest back to the end-user; changing at least one of the service dataentries in the application service definition without changing theservice name; receiving a second service request from the end-user,wherein the second service request is substantially equal to the firstservice request; translating the second service request into a secondapplication request, wherein the second application request issubstantially different from the first application request, and whereinthe translating is at least partially based on the changed applicationservice definition; and redirecting the second application request backto the end-user.
 19. The method of claim 18, wherein the one or moreservice data entries of the application service definition includeparameters for enablement and disablement.
 20. The method of claim 18,wherein the method is performed in an order as recited in claim
 18. 21.A method for registering services on a web dispatch server, the methodcomprising: sending a registration request from a host to the webdispatch server, the registration request having a first service name;processing the registration request on the web dispatch server;registering a new service for the registration request on the webdispatch server, the new service having a second service name; andstoring the new service in a web dispatch database, such that a user canaccess the new service of the host by sending a service request to theweb dispatch server.
 22. The method of claim 21, wherein the firstservice name is substantially equal to the second service name.
 23. Themethod of claim 21, wherein the registration request further includesone or more service parameters.
 24. The method of claim 23, wherein thenew service further includes one or more service parameters.
 25. Themethod of claim 21, wherein the one or more service parameters of theregistration request include a Universal Resource Locator.
 26. Themethod of claim 21, wherein the one or more service parameters of thenew service include a Universal Resource Locator.
 27. The method ofclaim 21, and further comprising displaying a web dispatch service userinterface screen.
 28. The method of claim 21, and further comprisingdisplaying currently registered services in the web dispatch database.29. A method for managing services on a web dispatch server, the methodcomprising: registering a service definition of an application server onthe web dispatch server, wherein the service definition includes a nameand one or more parameters, and wherein the web dispatch server includesa web dispatch database; storing the service definition in the webdispatch database; sending a first service command from a browser to theweb dispatch server; sending a first application request from the webdispatch server back to the browser; editing the one or more parametersof the service definition; sending a second service command from thebrowser to the web dispatch server; and sending a second applicationrequest from the web dispatch server back to the browser, wherein thefirst and second service commands are substantially equal, and whereinthe first and second application requests are substantially different.30. The method of claim 29, and further comprising displaying currentlyregistered services in the web dispatch database.
 31. The method ofclaim 29, and further comprising deleting the one or more parameters ofthe service definition from the web dispatch database.
 32. The method ofclaim 29, and further comprising deleting the service definition fromthe web dispatch database.
 33. A method for discovering servicesavailable on a web dispatch provider, the method comprising: sending aservices information query from a browser to the web dispatch provider;searching a web dispatch provider database for all service definitionsregistered with the web dispatch provider, wherein each servicedefinition includes a name, one or more required parameters, and adescription; and sending a list of all service definitions registeredwith the web dispatch provider back to the browser.
 34. A method forcompleting an application command on a web dispatch server, the methodcomprising: receiving a service request from a client computer, whereinthe service request includes only a subset of required applicationparameters, and wherein the client computer includes a web browser;translating the service request into an application request, wherein oneor more default application parameters are inserted into the applicationrequest; and returning the application request to the client computer.35. The method of claim 34, and further comprising sending theapplication request from the client computer to an application server.36. A method for formatting parameters of an application command on aweb dispatch server, the method comprising: receiving a service commandfrom a client computer, wherein the service command includes one or moreunformatted parameters, and wherein the client computer includes a webbrowser; translating the service command into an application link,wherein the one or more unformatted parameters of the service commandare translated into one or more formatted parameters of the applicationlink; and returning the application link to the client computer.
 37. Themethod of claim 36, and further comprising sending the application linkfrom the client computer to an application server.
 38. The method ofclaim 36, wherein the client computer is another application server. 39.A method of generating form data in a web dispatching system, the methodcomprising: directing a service request command from a browser to adispatch server; transforming the service request command into anapplication command, wherein the application command includes form data;and redirecting the application command back to the browser.
 40. Themethod of claim 39, wherein the service request command does not includeany form data.
 41. The method of claim 39, and further comprisingsending the application command from the browser to an applicationserver.
 42. The method of claim 39, wherein the sending of theapplication command from the browser to the application server isexecuted with a POST method.
 43. The method of claim 39, wherein thebrowser stores the service request as a browser bookmark.
 44. The methodof claim 39, wherein the form data includes an invocation of an onloadevent that calls a submit method.
 45. The method of claim 39, whereinthe directing of a service request command is executed with a GETmethod.
 46. A method for achieving parameter transparency on a webdispatch provider, the method comprising: receiving a service requestfrom a client computer, wherein the service request includes one or moreparameters that are not defined in a database of the web dispatchprovider; translating the service request into an application link,wherein the one or more parameters are transparently copied from theservice request into the application link; dispatching the applicationlink to the client computer; and sending the application link from theclient computer to an application server.
 47. The method of claim 46,wherein the translating of the service request into the application linkincludes supplying default parameter values.
 48. A computer-readablemedium having instructions stored thereon to perform a computerizedmethod comprising: receiving a service invocation from an end-user to adispatch server; processing the service invocation on the dispatchserver; translating the service invocation on the dispatch server intoan application command to an application server, wherein the translatingis at least partially based on a service definition stored on thedispatch server; and redirecting the application command to theend-user.
 49. The computer-readable medium of claim 48, wherein theprocessing of the service invocation includes validating the serviceinvocation.
 50. The computer-readable medium of claim 48, wherein theprocessing of the service invocation includes checking the serviceinvocation for parameters.
 51. A computer-readable medium havinginstructions stored thereon to perform a computerized method comprising:registering a service definition of a service provider on a web dispatchserver; receiving a first service request on the web dispatch serverfrom an end-user; sending a first application request from the webdispatch server back to the end-user; editing the service definition;receiving a second service request on the web dispatch server from theend-user; and sending a second application request from the web dispatchserver back to the end-user, wherein the first and second servicerequests are substantially equal, and wherein the first and secondapplication requests are substantially different.
 52. Thecomputer-readable medium of claim 51, wherein the computerized methodfurther includes displaying currently registered services on the webdispatch server.
 53. The computer-readable medium of claim 51, whereinthe computerized method further includes deleting one or more parametersfrom the service definition on the web dispatch server.
 54. Thecomputer-readable medium of claim 51, wherein the computerized methodfurther includes deleting the service definition from the web dispatchserver.
 55. A computer-readable medium having instructions storedthereon to perform a computerized method comprising: receiving aservices information query on a web dispatch server, wherein theservices information query is sent from an end-user; searching a webdispatch server database for all service definitions registered with theweb dispatch server, wherein each service definition include a name; andsending a list of all service definitions registered with the webdispatch server back to the end-user.
 56. A method for source routing ona web dispatch server, the method comprising: sending a service commandfrom a requester to the web dispatch server; determining whichapplication server that provides the requested service is closest to therequestor; translating the service command into an application request,wherein the translating is at least partially based on the determinationof the closest application server; and redirecting the applicationrequest to the requester.
 57. A method for load-balancing of applicationservers, the method comprising: sending a service request from arequestor to a web dispatch server; determining which applicationservers that each provide the requested service are situated in alocation that is substantially the same as that of the requester;selecting one of the application servers to be the destinationapplication server, wherein the selecting is at least partially based ona load-balancing strategy; translating the service request into anapplication request, wherein the translating is at least partially basedon the destination application server; and redirecting the applicationrequest to the requester.
 58. The method of claim 57, wherein theload-balancing strategy is a round-robin strategy.
 59. A computer datasignal embodied in a carrier wave and representing a sequence ofinstructions that, when executed by a computer, cause the computer toperform a computerized method comprising: receiving a service requestfrom a requestor to a dispatch server; validating the service request;checking the service request for parameters; translating the servicerequest on the dispatch server into an application request to anapplication server, wherein the translating is at least partially basedon a service definition stored on the dispatch server; and redirectingthe application request to the requestor.
 60. A propagated signalcarrying computer-readable information representing a computer programthat performs a computerized method comprising: registering a servicedefinition of a service provider on a web dispatch provider; translatinga first service request from an end-user into a first content request;sending the first content request from the web dispatch provider to theend-user; editing the service definition; translating a second servicerequest from the end-user into a second content request; and sending thesecond content request from the web dispatch provider to the end-user,wherein the first and second service requests are substantially equal,and wherein the first and second content requests are substantiallydifferent.
 61. A computerized method for using a web dispatch server,the method comprising: adding a service to a database of the webdispatch server, the service having a service definition; sending aservice discovery request from a client to the web dispatch server;modifying the service definition in the database of the web dispatchserver; sending a service request from the client to the web dispatchserver; querying the database of the web dispatch server; andtranslating the service request into an application command.
 62. Themethod of claim 61, wherein the method is performed in an order asrecited in claim
 61. 63. The method of claim 61, and further comprisingredirecting the application command back to the client.
 64. The methodof claim 61, and further comprising: sending the application commandfrom the web dispatch server to an application server; sending a resultfrom the application server to the web dispatch server; and sending theresult from the web dispatch server to the client.
 65. The method ofclaim 61, and further comprising removing the service from the databaseof the web dispatch server.